home *** CD-ROM | disk | FTP | other *** search
- From: mh1@irz301.inf.tu-dresden.de (Michael Hohmuth)
- Subject: Re: MiNT goes UNiX, invitation for mailing list
- Date: Wed, 12 Jan 1994 14:13:08 +0100 (MET)
- In-Reply-To: <199401121154.AA05559@avignon.daimi.aau.dk> from "Christian Lynbech" at Jan 12, 94 12:54:50 pm
- Mime-Version: 1.0
-
- > > Btw., why not just using __MINT__ as a compiler switch, it is
- > > predefined by the MiNTlibs and independent of the compiler. For
- > > compiler dependent code we can use atarist for GCC, ??? for PureC, and
- > > so on.
-
- > Because people have already used __MINT__ in an incompatible way, I
- > believe. For instance, in tcsh, the startup file is named cshrc.csh
- > (not .cshrc) on the atari.
-
- Well, the `tcsh' port uses "#ifdef TOSFS" instead of "#ifdef __MINT__"
- for this very purpose. If you recompile without TOSFS defined, you
- get what you want.
-
- I don't know why you always cite the `tcsh' port as an example of how
- __MINT__ is incompatibly used. I believe that the `tcsh' port uses
- __MINT__ in the correct way, meaning "if using MiNT Library, do this".
- (And I should know, I did it. ;-)
-
- > So it would beb better to tie the choice between the two types:
- > `maximum unix conformance' and `maximum tos compability' to a brand
- > new switch, whether that would be a I_WANT_UNIX or I_WANT_TOS.
-
- Perhaps we should extend the MiNT Library with an extra switch
- _UNIX_SOURCE meaning "maximum unix conformance". _TOS_SOURCE could
- mean "maximum tos compability". _MINT_SOURCE could mean what the
- current default with mntlib is, but I could also imagine _UNIX_SOURCE
- being the default.
-
- Besides, this way we won't need another library.
-
- Michael
- --
- Internet: hohmuth@freia.inf.tu-dresden.de
-